Many computing systems (personal computers, smart telephones, cable and satellite receivers, DVD players, Blu-ray players, flash-based music players to name a few) utilize a unified memory architecture (UMA) in which the computer processing unit (CPU) communicates with an external memory to store and retrieve data. These data may represent software code, encryption and decryption keys, text, audio, video among other valuable assets. While this architecture is flexible and relatively inexpensive, the external memory is vulnerable to unauthorized access.
In order to utilize the processor efficiently, systems within the computing system may be permitted to have direct access to the external memory (referred to herein as “direct memory access” or “DMA”). Memory access may also be managed by a memory management unit (MMU). A MMU divides the virtual address space (the range of addresses used by the processor) into pages. An application may be allocated certain pages within the virtual memory dynamically and will access the allocated area of memory for the duration of a task. By assigning a program its own virtual space, an operating system can utilize an MMU to impose a form of memory protection against a compromised or foreign application.
One common attack vector for accessing memory content is to use code insertion. For example, software flaws such as buffer/heap overflow vulnerabilities may be used to run unauthorized code on a system. Once an attacker can run its own code on a system, the unified memory between CPU and functional units with DMA is a weak point from a security point of view. For example, units with DMA capabilities can be used to transfer code or data toward external peripherals or possibly to fully overwrite the software stack. In addition, hacked code can be used to observe sensitive data used by some CPU process or by some functional units. This can be done because in most embedded systems, the whole memory space is accessible to all the units with DMA capabilities.
In order to secure the UMA, embodiments described here isolate the shared memory from access by particular processes. One approach to isolate a CPU process is to use the MMU. However, the MMU does not provide control over the DMA performed by hardware functional units, so every device driver and system peripheral can, in principle, access every memory location. For example, although a device driver is prevented from using the CPU to write to a particular page of system memory (perhaps because the page does not belong to the driver's memory space), it may instead program its hardware device to perform a DMA to the page. Thus, a compromised driver could use the DMA capability of the interface port it controls to output the whole memory to the external world or to overwrite code to implement another level of attack.
In some systems, some part of memory can be reserved so as to be accessible by only a few sets of selected functional units. This approach limits memory management flexibility as a specific area of memory must be reserved to specific functional units. This is difficult to implement as it means that all the different operational flows between functional units must be known at design time to ensure the hardware is able to accommodate them. It also impacts software as it means that dynamic memory allocation must take into account the type of data when reserving memory. Also it means that support units such as CPU or hardware accelerators cannot be used to perform operations such as block move.